Computer-aided software engineering (CASE) systems have been developed to assist computer programmers in the construction, test and maintenance of complex computer software. Such systems assist the programmer in building or compiling the program and in analyzing the program, both statically and dynamically. Modern CASE systems are intended to operate in an environment where teams of programmers work on the development of a complex program. In many instances, CASE systems operate with a window-based user interface.
CASE systems typically involve a number of different software tools, or programs, designed to assist in program development. Such tools typically include a program edit tool, a build tool, a debug tool and a version management tool. The tools may be integrated to cooperate over a problem domain to further facilitate automation of software development tasks. CASE systems typically utilize the UNIX operating system or modifications of the UNIX operating system. (UNIX is a registered trademark of AT&T in the USA and other countries.) Software can be developed on CASE systems efficiently without requiring programmers to have a detailed knowledge of the development tools or the underlying operating system.
It is frequently desirable to customize CASE systems for particular applications. It is not uncommon for programmers in a particular industry or technical field to rely upon specialized programs, or development tools, because of the nature of the programs which they are developing. For example, programmers working with engineering design programs may rely on one or more specialized development tools, while programmers working with telecommunication programs may rely on an entirely different set of specialized development tools. Such tools may include, for example, UNIX system tools that are not frequently used or tools that are specially developed for a particular application.
A technique for integrating specialized development tools, also known as application tools, into a CASE system is disclosed in U.S. Pat. No. 5,075,847 issued Dec. 24, 1991 to Fromme, which is hereby incorporated by reference. The disclosed technique, commonly known as encapsulation, permits application tools to be integrated into a CASE system without reengineering the application tool and using only the binary code of the application tool. The application tool is integrated, or encapsulated, into the CASE system by providing an interface program which controls communication between the application tool and the remainder of the system. The interface program responds to predefined application tool events and to events in the remainder of the system that require communication with the application tool. Thus, all inputs and outputs of the application tool are controlled by the interface program.
It is frequently desirable to encapsulate a class of application tools known as full screen programs into a CASE system. A full screen application tool is one that places text in fixed locations on a display screen. A well-known example of a full screen application tool is a spreadsheet program. When a screen-oriented application tool is encapsulated into a CASE system, it is desirable to recognize specified output conditions of the application tool and to react to them. For example, it may be desirable to determine when the text in a predefined region of the screen changes or when the text matches a desired pattern. These conditions or events must be recognized without modification of the application tool code.
The most obvious way to recognize application tool events is to search through the buffer which represents the display screen for a text string pattern which matches a desired output condition. This approach has a basic weakness. Searching in bulk does not focus on the types of output conditions that normally occur with screen based programs such as "vi", "xdb" or "isql". Some of these programs have screen events of interest that are based solely upon cursor movement and position, not text in the buffer. Simply searching the screen buffer also does not permit recognition of events that are a hybrid of text events and cursor events. Another problem is that some text related events are not easily described by a pattern. For example, the program might output peoples' names, which do not match a specific pattern string. Also a pattern search of the screen buffer may result in several matches when only one is of interest. Finally, this technique has problems in controlling repeat matches. When a pattern matches, it will match repeatedly until the text changes. Avoiding this adds complexity to the event recognition mechanism.